home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 206 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.5 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.std.c
  4. Subject: Re: Hungarian notation
  5. Date: 27 Jan 1996 12:46:50 -0600
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4edruq$s6h@solutions.solon.com>
  8. References: <30C40F77.53B5@swsbbs.com> <4eco1g$aih@fountain.mindlink.net> <4ecqkn$p1t@solutions.solon.com> <4edore$sh1@fountain.mindlink.net>
  9. NNTP-Posting-Host: solutions.solon.com
  10.  
  11. In article <4edore$sh1@fountain.mindlink.net>,
  12. Gene Wirchenko <genew@mindlink.bc.ca> wrote:
  13. >>My understanding is that integer conversions are an implementation
  14. >>defined *RESULT*.  No other *behavior* is allowed - the semantics do
  15. >>not imply or show any.
  16.  
  17. >     Is this defined in the Standard?
  18.  
  19. !
  20. Not that I can find; perhaps this is a bug.
  21.  
  22. >>However, given something where the *result* is implementation defined, I
  23. >>would expect that no unexpected *behavior* was allowed.
  24.  
  25. >     A result is a behavior, no?
  26. >     Gah, the arguments over wording.  Next: "How many angel can dance
  27. >on the end of a C pointer?"
  28.  
  29. No; a result of type int is some value representable in type int; a
  30. behavior is not constrained to be that limited.
  31.  
  32. This is probably a standard weakness; it simply assumes that people will
  33. distinguish between implementation defined behavior (the contents and
  34. interpretation of the string passed to the system function) and
  35. implementation defined behavior (whether a plain char has the same range
  36. of values as signed or unsigned char.)  The latter implicitly provides
  37. room for only two answers - signed or unsigned.  Similarly, when they
  38. say a "result" is imp. defined, we generally assume they mean "the
  39. result of the expression", because that's how it would work if they were
  40. speaking English, in context.
  41.  
  42. (Several other things define the "result" of an expression.)
  43.  
  44. >>Because none are specified.  The semantics of the >> operator on signed
  45. >>ints are implementation specified (or is that defined?) but no one would
  46. >>tolerate it formatting disks, because it doesn't say it can, and the
  47. >>wording makes it clear that no extra behavior is expected.
  48.  
  49. >     Doesn't none specified mean that the implementation is free to
  50. >play hopscotch with nasal demons?
  51.  
  52. No.
  53.  
  54. When *no behavior at all* is specified, you get undefined behavior.
  55.  
  56. When *ANY* behavior at all is specified, it is assumed to be exhaustive.
  57. For instance, when the Standard says "free(NULL) has no effect", we do
  58. not consider it acceptable for it to have no effect, and to *also* crash
  59. the computer.  The behavior listed is presumed exhaustive unless stated
  60. otherwise.
  61.  
  62. >     My point is that if the value can't be represented then it's
  63. >hardly the case that a conversion is being performed.  If you consider
  64. >butchering a value to an implementation defined value to be
  65. >conversion, gah.
  66.  
  67. Well, the conversion is a source-level detail.
  68. Given
  69.     int i;
  70.     char ch;
  71. we call
  72.     ch = i;
  73. an implicit conversion, and
  74.     ch = (char) i;
  75. an explicit conversion.
  76.  
  77. That's a conversion; whether the *result* is meaningful or not may vary.
  78. If i's value fits in a char, we are told the result will be meaningful.
  79. If it won't, we are told the implementation will give us rules for it.
  80. This doesn't sound like the implementation is allowed to define rules
  81. for anything beyond what the correlation of char to int values is.
  82.  
  83. -s
  84. -- 
  85. Peter Seebach - seebs@solon.com - Copyright 1995 Peter Seebach.
  86. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  87. Using trn?  Weird new newsgroup problem?  I know the fix!  Email me!
  88. The *other* C FAQ - ftp taniemarie.solon.com /pub/c/afq - Not A Flying Toy
  89.